From: Jann Horn Date: Wed, 31 Aug 2022 19:13:48 +0000 (+0200) Subject: mm: Force TLB flush for PFNMAP mappings before unlink_file_vma() X-Git-Tag: archive/raspbian/5.10.140-1+rpi1^2~15 X-Git-Url: https://dgit.raspbian.org/%22http://www.example.com/cgi/%22/%22http:/www.example.com/cgi/%22?a=commitdiff_plain;h=f612099c75782e61abb4a1c7e83247ec7b358ea0;p=linux.git mm: Force TLB flush for PFNMAP mappings before unlink_file_vma() From jannh@google.com Wed Aug 31 21:19:43 2022 To: stable@vger.kernel.org Cc: Peter Zijlstra , Will Deacon , Linus Torvalds Message-ID: <20220831191348.3388208-1-jannh@google.com> commit b67fbebd4cf980aecbcc750e1462128bffe8ae15 upstream. Some drivers rely on having all VMAs through which a PFN might be accessible listed in the rmap for correctness. However, on X86, it was possible for a VMA with stale TLB entries to not be listed in the rmap. This was fixed in mainline with commit b67fbebd4cf9 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"), but that commit relies on preceding refactoring in commit 18ba064e42df3 ("mmu_gather: Let there be one tlb_{start,end}_vma() implementation") and commit 1e9fdf21a4339 ("mmu_gather: Remove per arch tlb_{start,end}_vma()"). This patch provides equivalent protection without needing that refactoring, by forcing a TLB flush between removing PTEs in unmap_vmas() and the call to unlink_file_vma() in free_pgtables(). [This is a stable-specific rewrite of the upstream commit!] Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman Gbp-Pq: Topic bugfix/all Gbp-Pq: Name mm-force-tlb-flush-for-pfnmap-mappings-before-unlink_file_vma.patch --- diff --git a/mm/mmap.c b/mm/mmap.c index a1ee93f55ce..b69c9711bb2 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2669,6 +2669,18 @@ static void unmap_region(struct mm_struct *mm, tlb_gather_mmu(&tlb, mm, start, end); update_hiwater_rss(mm); unmap_vmas(&tlb, vma, start, end); + + /* + * Ensure we have no stale TLB entries by the time this mapping is + * removed from the rmap. + * Note that we don't have to worry about nested flushes here because + * we're holding the mm semaphore for removing the mapping - so any + * concurrent flush in this region has to be coming through the rmap, + * and we synchronize against that using the rmap lock. + */ + if ((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) != 0) + tlb_flush_mmu(&tlb); + free_pgtables(&tlb, vma, prev ? prev->vm_end : FIRST_USER_ADDRESS, next ? next->vm_start : USER_PGTABLES_CEILING); tlb_finish_mmu(&tlb, start, end);